I think this should be low priority, given bz1895323 was addresses/worked-around.

I also wonder if we should make this an upstream feature request, and not a downstream one.

This is related to this patch:
https://listman.redhat.com/archives/libguestfs/2021-November/msg00139.html

The issue is that the powershell command we use to fix the date to schtasks
seems wrong.  However it still appears to work OK when run in virt-v2v
(not when the same command is run by hand however).

The patch does look like it is correct, and we should likely use it anyway,
but the fact that virt-v2v is not broken is a little bit worrying.

The patch which fixes this (if it's a bug) is upstream in
commit d9dc6c42ae64ba92993dbd9477f003ba73fcfa2f and included
in RHEL 9.0.

Verify the bug with below builds:
virt-v2v-1.45.97-3.el9.x86_64
libguestfs-1.46.1-2.el9.x86_64
guestfs-tools-1.46.1-6.el9.x86_64
libvirt-libs-8.0.0-3.el9.x86_64
qemu-img-6.2.0-7.el9.x86_64
nbdkit-1.28.5-1.el9.x86_64
libnbd-1.10.4-1.el9.x86_64


Steps:
1.Prepare a guest which Change region format to "Chinese" and the short date format to 'yy.M.d' on VMware
1.1  Open poweshell in guest and execute schtasks.exe command with old $FormatHack = ($([System.Globalization.DateTimeFormatInfo]::CurrentInfo.ShortDatePattern) -replace 'M+/', 'MM/') -replace 'd+/', 'dd/', can reproduce the error of comment0, details please check the screenshot 'formathack-comment7'
1.2  Open poweshell in guest and execute schtasks.exe command with new $FormatHack = (($([System.Globalization.DateTimeFormatInfo]::CurrentInfo.ShortDatePattern) -replace 'y+', 'yyyy') -replace 'M+', 'MM') -replace 'd+', 'dd', the task can be created successfully, details please check the screenshot 'formathack-comment7'

2.Power off the guest, then convert the guest from VMware to rhv by v2v
# virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0.2 -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA  -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 -n ovirtmgmt esx6.7-win2022-x86_64-uefi -oo rhv-direct=true
[   0.0] Setting up the source: -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk esx6.7-win2022-x86_64-uefi
[   2.2] Opening the source
[  10.2] Inspecting the source
[  15.6] Checking for sufficient free disk space in the guest
[  15.6] Converting Windows Server 2022 Standard to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  25.3] Mapping filesystem data to avoid copying unused and blank areas
[  26.6] Closing the overlay
[  26.8] Assigning disks to buses
[  26.8] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[  26.8] Setting up the destination: -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data
[  48.2] Copying disk 1/1
█ 100% [****************************************]
[1512.7] Creating output metadata
[1575.8] Finishing off

3.Check guest after conversion, checkpoints of guest are passed


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 (new packages: virt-v2v), 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/RHEA-2022:2566