Bug 1883588

Summary: VMware VM using SATA for disk cannot be migrated
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Fabien Dupont <fdupont>
Component: libvirtAssignee: Pino Toscano <ptoscano>
Status: CLOSED ERRATA QA Contact: liuzi <zili>
Severity: high Docs Contact:
Priority: unspecified    
Version: 8.2CC: ddepaula, jdenemar, jsaucier, juzhou, mkalinin, mxie, ptoscano, rjones, tyan, tzheng, virt-maint, xiaodwan, zili
Target Milestone: rcKeywords: Automation
Target Release: 8.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-6.10.0-1.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1883802 (view as bug list) Environment:
Last Closed: 2021-05-25 06:43:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version: 6.9.0
Embargoed:
Bug Depends On:    
Bug Blocks: 1677608    
Attachments:
Description Flags
VMX file with SATA disk none

Description Fabien Dupont 2020-09-29 16:03:17 UTC
Created attachment 1717579 [details]
VMX file with SATA disk

Description of problem:

When migrating a VMware VM that uses SATA bus for disks, virt-v2v doesn't detect the disk and the migration fails. The log file says that the VM "has no non-removable disks".

The libvirtxml dump is:

<domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'>
  <name>w2019biosvmware</name>
  <uuid>421a6177-5aa9-abb7-5924-fc376c18a1b4</uuid>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <cputune>
    <shares>2000</shares>
  </cputune>
  <os>
    <type arch='x86_64'>hvm</type>
  </os>
  <cpu>
    <topology sockets='1' dies='1' cores='2' threads='1'/>
  </cpu>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <interface type='bridge'>
      <mac address='00:50:56:9a:9c:7a'/>
      <source bridge='VM Network'/>
      <model type='e1000e'/>
    </interface>
    <video>
      <model type='vmvga' vram='8192' primary='yes'/>
    </video>
  </devices>
  <vmware:datacenterpath>Datacenter</vmware:datacenterpath>
  <vmware:moref>vm-22</vmware:moref>
</domain>

Version-Release number of selected component (if applicable): 8.2.1


How reproducible: Always


Steps to Reproduce:
1. Create a VMware VM with SATA disk
2. Import the VM with virt-v2v

Actual results: Migration fails


Expected results: Migration succeeds


Additional info: Attached is a real VMMX file provided by a customer.

Comment 1 Pino Toscano 2020-09-29 16:16:24 UTC
I will take a look at this, and see how the guest in VMware works.

Comment 2 Pino Toscano 2020-09-30 09:40:21 UTC
virt-v2v already handles SATA disks internally, also when parsing them from a libvirt XML.

The problem is that the VMX parser in libvirt (used by the esx driver) does not parse SATA disks at all; implemeting it requires some guesswork of how SATA disks/controllers are handled internally in VMware, and how these bits are exposed in VMX files.
Hence, reassigning to libvirt.

Comment 4 Richard W.M. Jones 2020-09-30 12:23:11 UTC
(In reply to Pino Toscano from comment #2)
> virt-v2v already handles SATA disks internally, also when parsing them from
> a libvirt XML.

We should probably fix v2v/input_vmx.ml (ie. -i vmx) as well.  Do we
need to clone this bug for virt-v2v for this?

Comment 5 Pino Toscano 2020-09-30 15:26:27 UTC
(In reply to Richard W.M. Jones from comment #4)
> (In reply to Pino Toscano from comment #2)
> > virt-v2v already handles SATA disks internally, also when parsing them from
> > a libvirt XML.
> 
> We should probably fix v2v/input_vmx.ml (ie. -i vmx) as well.  Do we
> need to clone this bug for virt-v2v for this?

This is why I already cloned it as bug 1883802 ...

Comment 6 Pino Toscano 2020-10-14 10:56:34 UTC
Fixed upstream for libvirt 6.9.0:

commit 2214fe90442c0f66359e5def3c3033bae0c60102 (HEAD -> master, origin/master, origin/HEAD)
Author: Pino Toscano <ptoscano>
Date:   Mon Oct 12 17:06:59 2020 +0200

    vmx: start parsing SATA disks
    
    Always reverse-engineering VMX files, attempt to support SATA disks in
    guests, and their controllers.
    
    The esx-in-the-wild-10 test case is taken from RHBZ#1883588, while the
    result of esx-in-the-wild-8 is updated with SATA disks.
    
    Fixes (hopefully):
    https://bugzilla.redhat.com/show_bug.cgi?id=1677608
    https://bugzilla.redhat.com/show_bug.cgi?id=1883588
    
    Signed-off-by: Pino Toscano <ptoscano>
    Reviewed-by: Michal Privoznik <mprivozn>

 src/vmx/vmx.c                                    | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/vmx2xmldata/vmx2xml-esx-in-the-wild-10.vmx | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/vmx2xmldata/vmx2xml-esx-in-the-wild-10.xml |  36 ++++++++++++++++++++++++++++++++++++
 tests/vmx2xmldata/vmx2xml-esx-in-the-wild-8.xml  |   6 ++++++
 tests/vmx2xmltest.c                              |   1 +
 5 files changed, 282 insertions(+)

commit 18a1dd57cd32493ce1124f2f1400811ccc9815b7
Author: Pino Toscano <ptoscano>
Date:   Mon Oct 12 13:33:45 2020 +0200

    vmx: expand the disk array
    
    Account for the possible SATA disks too, which means 120 potential
    disks.
    
    This means the size of the array triples, however that is unavoidable
    with the current way of reading disks.
    
    Signed-off-by: Pino Toscano <ptoscano>
    Reviewed-by: Michal Privoznik <mprivozn>

 src/vmx/vmx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

commit 11e61489ff6a7e03ed47629c6561228e5d4c09bb
Author: Pino Toscano <ptoscano>
Date:   Mon Oct 12 13:25:25 2020 +0200

    vmx: shortcut 'cdrom-image' as CD-ROM earlier
    
    Add it to the list of 'deviceType' values ignored for disks.
    
    Signed-off-by: Pino Toscano <ptoscano>
    Reviewed-by: Michal Privoznik <mprivozn>

 src/vmx/vmx.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

commit b23ee6394a34a9e3c0301dcdc8c65fb92b0f4e0c
Author: Pino Toscano <ptoscano>
Date:   Mon Oct 12 13:16:24 2020 +0200

    vmx: hide private helpers
    
    Move all the private helpers for parsing and formatting of domain
    elements as private static functions in vmx.c, to avoid using them
    directly.
    
    Signed-off-by: Pino Toscano <ptoscano>
    Reviewed-by: Michal Privoznik <mprivozn>

 src/libvirt_vmx.syms | 12 ------------
 src/vmx/vmx.c        | 62 ++++++++++++++++++++++++++++++++++++++++++++++----------------
 src/vmx/vmx.h        | 44 --------------------------------------------
 3 files changed, 46 insertions(+), 72 deletions(-)

Comment 12 liuzi 2020-12-25 13:20:18 UTC
Test the bug with builds:
virt-v2v-1.42.0-6.module+el8.4.0+8855+a9e237a9.x86_64
libvirt-6.10.0-1.module+el8.4.0+8898+a84e86e1.x86_64

Steps:
1.Prepare a guest with sata disk on ESX6.5 and make sure the guest can boot normally
2.Check the guest xml:
#virsh dumpxml Auto-esx6.5-rhel7.6-sata 
[...]
  <devices>
    <disk type='file' device='disk'>
      <source file='[esx6.5-function] esx6.5-rhel7.6-sata/esx6.5-rhel7.6-sata.vmdk'/>
      <target dev='sda' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='sata' index='0'/>
    <interface type='bridge'>
      <mac address='00:50:56:ac:94:8c' type='generated'/>
      <source bridge='VM Network'/>
      <model type='vmxnet3'/>
    </interface>
[...]

3.Use viert-v2v to convert the guest to rhv
# virt-v2v -ic vpx://root.73.141/data/10.73.196.89/?no_verify=1 Auto-esx6.5-rhel7.6-sata -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data -op /home/rhvpasswd -oo rhv-cafile=/home/ca.pem -oo rhv-cluster=Default -oo rhv-direct -of raw --password-file /home/passwd -b ovirtmgmt
[   0.3] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.196.89/?no_verify=1 Auto-esx6.5-rhel7.6-sata
[   3.1] Creating an overlay to protect the source from being modified
[   3.6] Opening the overlay
[  37.4] Inspecting the overlay
[ 116.5] Checking for sufficient free disk space in the guest
[ 116.5] Estimating space required on target for each disk
[ 116.5] Converting Red Hat Enterprise Linux Server 7.6 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[2027.7] Mapping filesystem data to avoid copying unused and blank areas
[2029.4] Closing the overlay
[2029.7] Assigning disks to buses
[2029.7] Checking if the guest needs BIOS or UEFI to boot
[2029.7] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data
[2031.0] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.UUuuYt/nbdkit4.sock", "file.export": "/" } (raw)
    (100.00/100%)
[2768.3] Creating output metadata
[2769.7] Finishing off

4.After finishing conversion,boot the guest in rhv,new guest can pass all regular checkpoints.

Result: Virt-v2v can convert guest with sata disk successfully. So change the bug from ON_QA to VERIFIED.

Comment 14 errata-xmlrpc 2021-05-25 06:43:36 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virt:av bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:2098