Created attachment 1737216 [details]
engine.log

Created attachment 1737217 [details]
v2v-can-convert-vmware-guest-disk-special-character.png

Created attachment 1737218 [details]
standalone-v2v-convert-guest-disk-have-special-character.log

I wonder if this is really on oVirt issue. I am not sure if we should change the name of the disk instead of failing as this is not transparent to (and may confuse) the clients.

Rich, what is your opinion on this? I have checked virt-v2v code and I cannot find anything that would handle invalid characters for any other output mode. I would assume you can run in to similar issues with other outputs too (e.g. libvirt or openstack). How are invalid characters handled for those?

From the virt-v2v point of view there are a few things to look at:

(1) The internal state of virt-v2v metadata, which is dumped in the log:

    source name: esx7.0-win2016-x86_64-time_yy-mm-dd
hypervisor type: vmware
       VM genid: 
         memory: 1073741824 (bytes)
       nr vCPUs: 1
     CPU vendor: 
      CPU model: 
   CPU topology: 
   CPU features: 
       firmware: unknown
        display: 
          video: vmvga
          sound: 
disks:
        nbd:unix:/tmp/v2vnbdkit.DbuQ32/nbdkit2.sock:exportname=/ (raw) [scsi]

Note that the source name is fine, and we don't actually store the disk name (it's
instead stored as a link to the nbdkit instance).

(2) Can the nbdkit instance access the source disk?  Yes - you can see
it gets the name from libvirt ([esx7.0-function] esx7.0-win2016-x86_64-yy%2fmm%2fdd/esx7.0-
win2016-x86_64-yy%2fmm%2fdd.vmdk)
and passes the same name to the VDDK plugin, which is able to open it fine.

(3) What is written in the oVirt metadata?  We give the disk a UUID,
but otherwise don't care about the original name:

        <rasd:Caption>Drive 1</rasd:Caption>
        <rasd:InstanceId>f20e664b-f3d7-4471-93ea-843e6129ee86</rasd:InstanceId>
        <rasd:ResourceType>17</rasd:ResourceType>
        <Type>disk</Type>
        <rasd:HostResource>f20e664b-f3d7-4471-93ea-843e6129ee86</rasd:HostResource>
[etc]

So as you say it's not something that should affect virt-v2v, and indeed
the virt-v2v conversion is successful.

I can't imagine why the disk name would affect anything.

Do we know what the actual failure is?  There's barely anything interesting
in engine.log, and I can't see anything at all in vdsm.log ...

(In reply to Richard W.M. Jones from comment #5)

> Do we know what the actual failure is?  There's barely anything interesting
> in engine.log, and I can't see anything at all in vdsm.log ...

I misunderstood the problem report. I thought the issue is with rhv-upload and the '/' in disk name cause the issues. But the issue is with web UI import (NB: '/' in disk name is completely valid character).

I tried to reproduce it and the problem seems to be NPE in engine:

2021-01-11 19:57:49,903+01 ERROR [org.ovirt.engine.core.bll.storage.repoimage.GetImagesListByStoragePoolIdQuery] (default task-25) [99ac4dac-5156-43de-adac-d9d
428fe84f6] Exception: java.lang.NullPointerException
        at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.storage.repoimage.GetImagesListByStoragePoolIdQuery.executeQueryCommand(GetImagesListByStor
agePoolIdQuery.java:39)
        at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(QueriesCommandBase.java:106)
        at org.ovirt.engine.core.dal//org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31)
        at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.executor.DefaultBackendQueryExecutor.execute(DefaultBackendQueryExecutor.java:14)
        at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.Backend.runQueryImpl(Backend.java:512)
        at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.Backend.runQuery(Backend.java:481)
        at jdk.internal.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.jboss.as.ee.3.GA-redhat-00004//org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodIntercept
or.java:52)


But it's possible I broke something on VMware side while trying. Ming, can you please attach more complete engine.log? The error we're looking for is before the lines you posted.

Changing to oVirt

Created attachment 1746599 [details]
engine-log-for-comment6

We need to rename the disk to cope with the naming convention on the oVirt side for disk aliases

Verified: 
ovirt-engine-4.5.1.3-0.36.el8ev
vdsm-4.50.2.1-1.el8ev.x86_64
libvirt-8.0.0-5.2.module+el8.6.0+15256+3a0914fe.x86_64
qemu-kvm-6.2.0-11.module+el8.6.0+15668+464a1f31.2.x86_64
virt-v2v-1.42.0-19.module+el8.6.0+15577+2ffd6ffa.x86_64

Verification scenario: 
1. Import VMware VM named 'esx7.0-win2016-x86_64-time_yy-mm-dd'
2. Verify VM imported successfully, Run VM and verify VM is running.

P.S. this issue is different than https://bugzilla.redhat.com/show_bug.cgi?id=1562602 where the correct behavior is to reject invalid characters, 
for example, when importing VM named centos44%/\&+=?!@#$^*()[]

This bugzilla is included in oVirt 4.5.2 release, published on August 10th 2022.
Since the problem described in this bug report should be resolved in oVirt 4.5.2 release, it has been closed with a resolution of CURRENT RELEASE.
If the solution does not work for you, please open a new bug report.