+++ This bug was initially created as a clone of Bug #1808610 +++

Description of problem:
When running a migration of a VM we are getting "Internal error: Missing essential config entry 'ide0:0.fileName'" and not able to proceed.

This can be reproduced with libvirt 6.0.0:

$ virsh -c 'esx://root@vmware?no_verify=1' domxml-from-native vmware-vmx A000-VPQB01.vmx
2020-02-28 07:28:11.700+0000: 99730: info : libvirt version: 6.0.0, package: 1.fc32 (Fedora Project, 2020-01-15-16:19:53, )
2020-02-28 07:28:11.700+0000: 99730: warning : esxConnectOpen:824 : Ignoring unexpected path '' for non-vpx scheme 'esx'
Enter root's password for vmware:
error: internal error: Missing essential config entry 'ide0:0.fileName'

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

How reproducible:
100%

--- Additional comment from Richard W.M. Jones on 2020-02-29 08:20:27 CET ---

I'm able to reproduce this with libvirt 6.0.0 in Fedora too.

--- Additional comment from Martin Kletzander on 2020-03-03 14:32:21 CET ---

Oh, so that happens with empty CD drive?

--- Additional comment from Lili Zhu on 2020-03-04 10:42:34 CET ---

(In reply to Martin Kletzander from comment #5)
> Oh, so that happens with empty CD drive?

after adding a line in the attached vmx file:
ide0:0.startConnected = "FALSE"
ide0:0.filename = "mydisk.vhd"       <== the added line
ide0:0.deviceType = "atapi-cdrom"
ide0:0.present = "TRUE"

# virsh -c 'esx://root.75.219?no_verify=1' domxml-from-native vmware-vmx b.vmx
2020-03-04 09:37:14.855+0000: 560975: info : libvirt version: 6.0.0, package: 7.virtcov.el8 (Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>, 2020-02-26-14:47:29, )
2020-03-04 09:37:14.855+0000: 560975: info : hostname: hostname
2020-03-04 09:37:14.855+0000: 560975: warning : esxConnectOpen:825 : Ignoring unexpected path '' for non-vpx scheme 'esx'
Enter root's password for 10.73.75.219: 
<domain type='vmware'>
  <name>T999-VPQB01</name>
  <uuid>9780d227-32b1-4dc8-ad95-1b031602e7ef</uuid>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <cputune>
    <shares>2000</shares>
  </cputune>
  <os firmware='efi'>
    <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>
    <disk type='file' device='disk'>
      <source file='[?] ?/A000-VPQB01_3.vmdk'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='disk'>
      <source file='[?] ?/A000-VPQB01_2.vmdk'/>
      <target dev='sdb' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <disk type='block' device='cdrom'>
      <source dev='mydisk.vhd'/>            <== the added ide disk filename 
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='scsi' index='0' model='lsisas1068'/>
    <controller type='ide' index='0'/>
    <interface type='bridge'>
      <mac address='00:50:56:be:9b:0b'/>
      <source bridge='VM Network'/>
      <model type='e1000'/>
    </interface>
    <video>
      <model type='vmvga' vram='4096' primary='yes'/>
    </video>
  </devices>
</domain>

Conversion succeed

--- Additional comment from Martin Kletzander on 2020-03-05 10:11:36 CET ---

Thanks, that could be an easy fix.  I'll look into that.

--- Additional comment from Martin Kletzander on 2020-03-17 10:53:25 CET ---

This is related to libvirt's "ignorance" of the following line in the config:

  ide0:0.startConnected = "FALSE"

The reason for that is we need to distinguish whether the VM is on or off, for a turned off VM this device should probably be visible, but for a started one we need to check the `present` parameter

There is a workaround for that and that is to either remove the cdrom or set:

  ide0:0.present = "false"

However this should get fixed.  The most important information for this to get fixed would be an actual documentation or description of what exactly do the keys mean because I can only guess.  I'll try to look up some documentation.  If anyone has better ideas or more info, feel free to jump in.

--- Additional comment from Pino Toscano on 2020-03-17 17:26:58 CET ---

First attempt to fix this posted:
https://www.redhat.com/archives/libvir-list/2020-March/msg00616.html

--- Additional comment from Pino Toscano on 2020-03-18 10:51:52 CET ---

v2:
https://www.redhat.com/archives/libvir-list/2020-March/msg00627.html

--- Additional comment from Pino Toscano on 2020-03-19 11:55:50 CET ---

Commits pushed upstream:

commit 9a469c0d358bf3fd4b4e55b20360620d6fda44b5
Author:     Pino Toscano <ptoscano>
AuthorDate: Wed Mar 18 10:29:51 2020 +0100
Commit:     Pino Toscano <ptoscano>
CommitDate: Thu Mar 19 11:25:16 2020 +0100

    vmx: shortcut earlier few 'ignore' cases in virVMXParseDisk()
    
    Move earlier the checks for skipping a hard disk when parsing a CD-DROM,
    and for skipping a CD-ROM when parsing a hard disk. This should have no
    behaviour changes, and avoids to add repeated checks in following
    commits.
    
    Signed-off-by: Pino Toscano <ptoscano>
    Reviewed-by: Ján Tomko <jtomko>
    Tested-by: Richard W.M. Jones <rjones>


commit c5ee737bc5c0fc61451e45ff41526270bdf0113c
Author:     Pino Toscano <ptoscano>
AuthorDate: Wed Mar 18 10:46:55 2020 +0100
Commit:     Pino Toscano <ptoscano>
CommitDate: Thu Mar 19 11:25:33 2020 +0100

    vmx: make 'fileName' optional for CD-ROMs
    
    It seems like CD-ROMs may have no 'fileName' property specified in case
    there is nothing configured as attachment for the drive. Hence, make
    sure that virVMXParseDisk() do not consider it mandatory anymore,
    considering it an empty block cdrom device. Sadly virVMXParseDisk() is
    used also to parse disk and floppies, so make sure that a NULL fileName
    is handled in cdrom- and floppy-related paths.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1808610
    
    Signed-off-by: Pino Toscano <ptoscano>
    Reviewed-by: Ján Tomko <jtomko>
    Tested-by: Richard W.M. Jones <rjones>