Does this affect virt-v2v?  Presumably it would stop us from
getting the libvirt XML which is the first step for VMware conversions.

(In reply to Richard W.M. Jones from comment #1)
> Does this affect virt-v2v?  Presumably it would stop us from
> getting the libvirt XML which is the first step for VMware conversions.

Yes, v2v conversion will be failed 

# virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0.2 -io  vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 esx7.0-win2016-date-yyyy-m-d-china   -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -ip /home/passwd -op /home/rhvpasswd  -os nfs_data  -b ovirtmgmt 
[   0.9] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2016-date-yyyy-m-d-china -it vddk  -io vddk-libdir=/home/vddk7.0.2 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78
virt-v2v: error: exception: libvirt: VIR_ERR_INTERNAL_ERROR: VIR_FROM_NONE: 
internal error: Missing essential config entry 'ethernet0.networkName'

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]

Martin, please have a look. This has increased in priority. Thanks.

I suppose this config describes a VM with a network adapter that is not connected to any network.  Is that what it looks like when this VM boots in VMWare?

(In reply to Martin Kletzander from comment #9)
> I suppose this config describes a VM with a network adapter that is not
> connected to any network.  Is that what it looks like when this VM boots in
> VMWare?

VM guest can boot into OS normally if there is no entry 'ethernet0.networkName' in guest vmx file and config setting, details pls refer to screenshots "guest-has-no-network-name-in-setting-and-vmx.png" and "guest-boot-normally-when-no-network-name-in-setting-and-vmx.png.png"

https://github.com/libguestfs/virt-v2v/blob/ddab06d5eb99696f5fd1073b8ec91efbc8c3e4ab/lib/types.ml#L67

This is what virt-v2v models internally, so fetching as much of that
information as possible would be what we want.  The most important
parts are the MAC address and the emulated network card (eg. "e1000e").

Reproduce the bug with below builds:
libvirt-libs-8.5.0-6.el9.x86_64
qemu-img-7.0.0-12.el9.x86_64


Steps to reproduce:

Scenario1:
1.1 Prepare a VMware guest and assign a network which is connected to a standard switch of ESXi host to the guest, but the guest vmx file doesn't have entry 'ethernet0.networkName' 

#cat esx7.0-rhel9.1-x86_64-uefi-without-secureboot.vmx |grep ethernet
ethernet0.virtualDev = "vmxnet3"
ethernet0.addressType = "vpx"
ethernet0.generatedAddress = "00:50:56:96:4d:83"
ethernet0.uptCompatibility = "TRUE"
ethernet0.present = "TRUE"
ethernet0.pciSlotNumber = "192"
ethernet0.exposeLargeBAR = "TRUE"

1.2 Use virsh to dump the guest xml from VMware
#  virsh -c vpx://root.213.107/data/10.73.212.38/?no_verify=1 dumpxml Auto-esx7.0-rhel9.1-x86_64-uefi-without-network-name
Enter root's password for 10.73.213.107: 
error: internal error: Missing essential config entry 'ethernet0.networkName'


Scenario2:
2.1 Prepare a VMware guest and assign a network which is connected to a distributed switch of ESXi host to the guest

# cat esx7.0-rhel8.4-with-VDS-network.vmx |grep ethernet
ethernet0.virtualDev = "vmxnet3"
ethernet0.dvs.switchId = "50 34 26 b2 94 e9 3b 16-1d 68 87 bf ff 4a 54 39"
ethernet0.dvs.portId = "7"
ethernet0.dvs.portgroupId = "dvportgroup-1285"
ethernet0.dvs.connectionId = "40347428"
ethernet0.shares = "normal"
ethernet0.addressType = "vpx"
ethernet0.generatedAddress = "00:50:56:b4:ed:5a"
ethernet0.uptCompatibility = "TRUE"
ethernet0.present = "TRUE"

2.2 Use virsh to dump the guest xml from VMware
# virsh -c vpx://root.227.27/data/10.73.225.34/?no_verify=1 dumpxml esx7.0-rhel8.4-with-VDS-network
Enter root's password for 10.73.227.27: 
error: internal error: Missing essential config entry 'ethernet0.networkName'


Test the bug with below builds:
libvirt-libs-8.7.0-1.el9.x86_64
qemu-img-7.1.0-1.el9.x86_64

Steps:
1. Use virsh to dump the guest xml of step1.1 from VMware
#   virsh -c vpx://root.213.107/data/10.73.212.38/?no_verify=1 dumpxml Auto-esx7.0-rhel9.1-x86_64-uefi-without-network-name
Enter root's password for 10.73.213.107: 
<domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'>
  <name>Auto-esx7.0-rhel9.1-x86_64-uefi-without-network-name</name>
....
    <interface type='null'>
      <mac address='00:50:56:96:4d:83' type='generated'/>
      <model type='vmxnet3'/>
    </interface>
.....

2. Use virsh to dump the guest xml of step2.1 from VMware
# virsh -c vpx://root.227.27/data/10.73.225.34/?no_verify=1 dumpxml esx7.0-rhel8.4-with-VDS-network
Enter root's password for 10.73.227.27: 
<domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'>
  <name>esx7.0-rhel8.4-with-VDS-network</name>
.....
<interface type='vds'>
      <mac address='00:50:56:b4:ed:5a' type='generated'/>
      <source switchid='503426b2-94e9-3b16-1d68-87bfff4a5439' portid='7' portgroupid='dvportgroup-1285' connectionid='40347428'/>
      <model type='vmxnet3'/>
    </interface>
......


Result:
   The bug has been fixed.

Verify the bug with below builds:
libvirt-client-8.7.0-1.el9.x86_64
qemu-img-7.1.0-1.el9.x86_64


Steps:
1.Prepare a ESXi host which has both standard switch and distributed switch, then prepare a guest which has two network devices, one is connected to distributed switch，which has network name 'DPortGroup', another one isn't connected any switch，which has empty network name


2.Use virsh to dump the guest xml from VMware
#  virsh -c vpx://root.227.27/data/10.73.225.34/?no_verify=1 dumpxml esx7.0-rhel8.4-x86_64
Enter root's password for 10.73.227.27: 
<domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'>
  <name>esx7.0-rhel8.4-x86_64</name>
    .....
    <interface type='vds'>
      <mac address='00:50:56:b4:4e:19' type='generated'/>
      <source switchid='503426b2-94e9-3b16-1d68-87bfff4a5439' portid='6' portgroupid='dvportgroup-1285' connectionid='136631795'/>
      <model type='vmxnet3'/>
    </interface>
    <interface type='null'>
      <mac address='00:50:56:b4:f0:1a' type='generated'/>
      <model type='vmxnet3'/>
    </interface>
    <video>
      <model type='vmvga' vram='8192' primary='yes'/>
    </video>
  </devices>
  <vmware:datacenterpath>data</vmware:datacenterpath>
  <vmware:moref>vm-122</vmware:moref>
</domain>


Result:
   The bug has been fixed, move the bug from ON_QA to VERIFIED

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 (libvirt 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-2023:2171