Bug 1468535

Created attachment 1295257 [details]
vdsm.log

This can't be debugged without the virt-v2v log, which VDSM
doesn't preserve.

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?

Created attachment 1295423 [details]
import.log

Same comment as:
https://bugzilla.redhat.com/show_bug.cgi?id=1468540#c6

Hi Ming Xie,

were you able to get verbose logs for this conversion?

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

(In reply to mxie 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?

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.

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).

*** This bug has been marked as a duplicate of bug 1484199 ***

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

(In reply to mxie 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

> 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

Created attachment 1429732 [details]
KVM-SATA

(In reply to mxie 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

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

(In reply to mxie 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.

Hi Sharon,

   Sorry for late reply, libvirt doesn't support disk bus=virtio-scsi now, only controller has virtio-scsi type，and guest-> disk-> interface should show guest‘s disk bus，so virtio-scsi shouldn't be shown in guest's disk interface on rhv4.2


Such as, import a SCSI-guest from kvm on rhv4.2, check the guest's disk bus after importing on registered host, its disk bus is SCSI, but guest's disk interface shows virtio-scsi,pls refer to screenshot "virtio-scsi"

# virsh dumpxml rhel8-SCSI
Please enter your authentication name: test
Please enter your password: 
<domain type='kvm' id='3'>
  <name>rhel8-SCSI</name>
 ....

    <disk type='file' device='disk' snapshot='no'>
      <driver name='qemu' type='qcow2' cache='none' error_policy='stop' io='threads'/>
      <source file='/rhev/data-center/mnt/10.66.144.40:_home_nfs__data/484255cb-cf10-4d22-ba81-32fdb29f0d21/images/1cba537d-432b-4ccd-bc8c-6aeb94b74967/7b9f02dc-19af-4559-b7f7-5e43f248e50c'/>
      <backingStore/>
      <target dev='sda' bus='scsi'/>
      <serial>1cba537d-432b-4ccd-bc8c-6aeb94b74967</serial>
      <boot order='1'/>
      <alias name='ua-1cba537d-432b-4ccd-bc8c-6aeb94b74967'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
.....

Created attachment 1454297 [details]
virtio-scsi

(In reply to mxie from comment #21)
> Hi Sharon,
> 
>    Sorry for late reply, libvirt doesn't support disk bus=virtio-scsi now,
> only controller has virtio-scsi type，and guest-> disk-> interface should
> show guest‘s disk bus，so virtio-scsi shouldn't be shown in guest's disk
> interface on rhv4.2
> 
> 
> Such as, import a SCSI-guest from kvm on rhv4.2, check the guest's disk bus
> after importing on registered host, its disk bus is SCSI, but guest's disk
> interface shows virtio-scsi,pls refer to screenshot "virtio-scsi"
> 
Hi Mxie,

Sorry for my late response. 
The reason for displaying the disk interface as "VIRTIO-SCSI" instead of just "SCSI" is not just to show the controller type used by this disk (in this case "SCSI") but also for showing the model of which the SCSI controller is using.

Since libvirt supports few models for SCSI controller, as taken from libvirt documentation on controller devices:
" scsi
 A scsi controller has an optional attribute model, which is one of 'auto',  'buslogic', 'ibmvscsi', 'lsilogic', 'lsisas1068', 'lsisas1078', 'virtio-scsi' or 'vmpvscsi'."

And since RHV supports only VIRTIO_SCSI model for SCSI controller devices, then we need to show the user which interface type and model the disk (or controller used by the disk) is using. 
In case of SCSI disk, you can't run such a disk without a correlated SCSI controller so RHV creates such a controller for you with the VIRTIO_SCSI model and that's the value shown in the UI under "disk interface" field.

Hope I helped understanding it a bit better...

Regards,
Sharon

This was fixed in oVirt bug 1484199 and there is nothing in libguestfs that would require changes. Please either close the bug right away or move to QE for verification if that is required.

Please re-test. Thanks.

Background:
   According to comment10, for importing from KVM sources, rhv uses tool called kvm2ovirt which will not convert/alter guest in any way.


Verify the bug with below builds:
*KVM host:rhel7.8 
  kernel-3.10.0-1111.el7.x86_64
  libvirt-4.5.0-23.el7_7.4.x86_64
  qemu-kvm-rhev-2.12.0-33.el7_7.7.x86_64
*RHV env:4.3.7.0-0.1.el7


Steps:
Scenario1:
1.1 Prepare a guest on virt-manager, disk dev is vda and bus is virtio
# virsh dumpxml esx6.0-rhel7.7-x86_64
<domain type='kvm'>
  <name>esx6.0-rhel7.7-x86_64</name>
  .....
    <disk type='volume' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source pool='default' volume='esx6.0-rhel7.7-x86_64-sda'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
....

1.2 Log in rhv and import guest from kvm, guest can be imported successfully and interface of disk shows Virtio on rhv


Scenraio2:
2.1 Prepare a guest on virt-manager, disk dev is hda and bus is IDE
# virsh dumpxml rhel7.8
....
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/home/Auto-kvm-rhel7.8-preallocatedqcow2-sda'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
......

2.2 Log in rhv and import guest from kvm, guest can be imported successfully and interface of disk shows IDE on rhv


Scenraio3:
3.1 Prepare a guest on virt-manager, disk dev is sda and bus is SATA
# virsh dumpxml rhel7.7-sata
....
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/home/Auto-kvm-rhel7.8-preallocatedqcow2-sda'/>
      <target dev='sda' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
......

3.2 Log in rhv and import guest from kvm, guest can be imported successfully and interface of disk shows VirtIO-SCSI on rhv


Scenraio4:
4.1 Prepare a guest on virt-manager, disk dev is sda and bus is SCSI
# virsh dumpxml rhel7.8-SCSI
....

  <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/home/Auto-kvm-rhel7.8-preallocatedqcow2-sda'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

......

4.2 Log in rhv and import guest from kvm, guest can be imported successfully and interface of disk shows VirtIO-SCSI on rhv


Result:
 1. Summary the result of importing guest from kvm host to rhv4.2 as below:
 
     Disk dev of kvm guest      Disk bus of kvm guest      After importing on rhv
     vdX                        virtio                     virtio
     hdX                        IDE                        IDE
     sdX                        SATA                       virtio-scsi
     sdX                        SCSI                       virtio-scsi

  2. According to comment23, virtio-scsi is used for controlling SATA/SCSI disk as a SCSI controller, so interface of disk shows VirtIO-SCSI is correct if import a SCSI/SATA guest from kvm source on rhv.

  3. I think original problem of comment0 actually was not a bug,I prefer to close the bug as NOTBUG, besides, rhv4.3 doesn't support importing guests from rhel8 yet, so change product to Red Hat Enterprise Linux 7.