Bug 1883588 - VMware VM using SATA for disk cannot be migrated
Summary: VMware VM using SATA for disk cannot be migrated
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libvirt
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: 8.3
Assignee: Pino Toscano
QA Contact: liuzi
URL:
Whiteboard:
Depends On:
Blocks: 1677608
TreeView+ depends on / blocked
 
Reported: 2020-09-29 16:03 UTC by Fabien Dupont
Modified: 2023-12-15 19:34 UTC (History)
13 users (show)

Fixed In Version: libvirt-6.10.0-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1883802 (view as bug list)
Environment:
Last Closed: 2021-05-25 06:43:36 UTC
Type: Bug
Target Upstream Version: 6.9.0
Embargoed:


Attachments (Terms of Use)
VMX file with SATA disk (3.30 KB, text/plain)
2020-09-29 16:03 UTC, Fabien Dupont
no flags Details

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


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