I can reproduce this one even upstream (on Fedora):

$ virt-builder fedora-35
$ virt-v2v -i disk fedora-35.img -o qemu -os /var/tmp/
$ ./fedora-35.sh 
qemu-system-x86_64: -balloon: invalid option

Deleting the -balloon option fixes the boot.

Note that commenting out the option is wrong because of the way that
the shell parses the script, eg:

command \
# comment \
arg

is parsed as: command # comment arg

So that probably explains the other failure.

(In reply to Richard W.M. Jones from comment #2)
> I can reproduce this one even upstream (on Fedora):
> 
> $ virt-builder fedora-35
> $ virt-v2v -i disk fedora-35.img -o qemu -os /var/tmp/
> $ ./fedora-35.sh 
> qemu-system-x86_64: -balloon: invalid option
> 
> Deleting the -balloon option fixes the boot.
> 
> Note that commenting out the option is wrong because of the way that
> the shell parses the script, eg:
> 
> command \
> # comment \
> arg
> 
> is parsed as: command # comment arg
> 
> So that probably explains the other failure.

Will pop up another error about CD-ROM device after deleting balloon in shell script and executing the shell, so there are two problems in the bug

# cat esx7.0-rhel8.5-x86_64.sh
#!/bin/sh -

/usr/libexec/qemu-kvm \
    -no-user-config \
    -nodefaults \
    -name esx7.0-rhel8.5-x86_64 \
    -machine q35,accel=kvm:tcg \
    -m 3072 \
    -drive file=/home/esx7.0-rhel8.5-x86_64-sda,format=raw,if=virtio,index=0,media=disk \
    -drive format=raw,if=scsi,bus=0,unit=0,media=cdrom \
    -netdev user,id=net0 \
    -device virtio-net-pci,netdev=net0,mac=00:50:56:83:b3:40 \
    -object rng-random,filename=/dev/urandom,id=rng0 \
    -device virtio-rng-pci,rng=rng0 \
    -device pvpanic,ioport=0x505 \
    -device vhost-vsock-pci \
    -serial stdio

# ./esx7.0-rhel8.5-x86_64.sh
qemu-kvm: -drive format=raw,if=scsi,bus=0,unit=0,media=cdrom: A block device must be specified for "file"

Partial patch posted (not including the CD-ROM fix):
https://listman.redhat.com/archives/libguestfs/2022-April/028656.html

The first part of this fix is upstream in:

https://github.com/libguestfs/virt-v2v/commit/14249248055bbe03b3334ca2a30cfbd7e7aab501
https://github.com/libguestfs/virt-v2v/commit/e3226dd431e7476cae2d0ca54b2332344de2d201

I had a look at the CD-ROM code (also in qemu) and it's making my
head hurt a little.  One major problem is that we're trying to
add a "virtio-blk CD-ROM", which is not a thing which qemu can model.
Stefan writes about why this is impossible here:

https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg00582.html

So that needs some deeper thought to fix.

(In reply to Richard W.M. Jones from comment #5)
> I had a look at the CD-ROM code (also in qemu) and it's making my
> head hurt a little.  One major problem is that we're trying to
> add a "virtio-blk CD-ROM"

Actually the statement above isn't quite true.  There's a path
through the code which tries to add a "virtio-blk CD-ROM", and
that is itself a different bug.  But in this particular case
mxie is trying to add a SCSI CD-ROM.  That should be possible,
but I cannot work out the qemu command line for adding a no-media
scsi-cd device.  It must be possible, surely, but all the ways
I've tried don't work, and as usual there's zero documentation.

Even if we add ",file=test1.img" to the current cdrom line, it fails
with:

> qemu-system-x86_64: -drive
> format=raw,if=scsi,bus=0,unit=0,media=cdrom,file=test1.img: machine
> type does not support if=scsi,bus=0,unit=0

(this happens for both i440fx and q35)

I only attempted this because I wanted to see, with "info qtree",
precisely what scsi controller this property would create. Turns out
that the answer is "none" -- we need to specify the controller model in
any case.

Assuming there is *at least one* element in
"target_buses.target_scsi_bus" that is
- either BusSlotDisk,
- or BusSlotRemovable with s_removable_type = CDROM,

then create a virtio-scsi controller like this:

  -device virtio-scsi-pci,id=virtio-scsi

and then for the individual devices, do:

- BusSlotDisk:

    -drive file=...,format=...,if=none,id=scsi-$i,media=disk \
    -device scsi-hd,bus=virtio-scsi.0,lun=$i,drive=scsi-$i

- BusSlotRemovable with s_removable_type = CDROM:

    -drive if=none,id=scsi-$i,media=cdrom \
    -device scsi-cd,bus=virtio-scsi.0,lun=$i,drive=scsi-$i

The only differences with BusSlotDisk are: "file=" and "format=" are
omitted from "-drive", "media" is "cdrom" not "disk" in "-drive", and
the device model is "scsi-cd", not "scsi-hd", in "-device"

Floppies are an *incredible mess*; they can't go on a scsi or virtio bus
at all it seems.

On "pc" only, a default floppy bus exists *even if* qemu is started with
"-nodefaults -no-user-config", so we don't have to (in fact, we *must
not*) create an "isa-fdc" controller (similar to virtio-scsi above)
manually. Just add, for each floppy:

  -drive if=none,id=floppy-$i,media=disk \
  -device floppy,bus=floppy-bus.0,unit=$i,drive=floppy-$i

Here note that "i" can be either 0 or 1, anything else is rejected.

On "q35", we *do* need to create the isa-fdc thing manually (similarly
to virtio-scsi above), with the *additional* option:

  -device isa-fdc,id=floppy-bus

I think things are actually looking good for floppies: the target bus assignment in "convert/target_bus_assignment.ml" appears appropriate for floppies (function "assign_removables"), and the libvirt output processes "target_floppy_bus" apparently correctly. The only issue is with the qemu output, which:

- attempts to deal with Floppy type removables on target_virtio_blk_bus, target_ide_bus, and target_scsi_bus -- which I think should never occur!,

- ignores target_floppy_bus altogether -- where I would expect *all* (if any) floppies to actually show up, from function "assign_removables"...

Let me look into this later.

Source VMware guest has a iso attched to the CD-ROM device, below is the xml about cdrom after converting the guest to local libvirt

#cat esx7.0-rhel8.5-x86_64.vmx  |grep c
drom -A 1
sata0:0.deviceType = "cdrom-image"
sata0:0.fileName = "/vmfs/volumes/1499ffe0-8dd77979/tools/os-installation-iso/RHEL-8.5.0-20211013.2-x86_64-dvd1.iso"


# virsh dumpxml esx7.0-rhel8.5-x86_64 |grep cdrom -A 5
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='sda' bus='scsi'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

(We don't try to copy over ISOs attached to guests.)

I have a (large-ish) patch. For an i440fx source (libvirt) domain, containing a fresh Fedora 35 install, and using 2 IDE-CDs, 2 IDE-HDs, 2 floppies, 2 virtio-block devices (the first one of those being the system disk), 2 SCSI-CDs, and 2 SCSI-HDs, it generates the following (functional) QEMU cmdline (note: the machine type is flipped to Q35):

qemu-system-x86_64 \
    -no-user-config \
    -nodefaults \
    -name disks-pc \
    -machine q35,accel=kvm:tcg \
    -m 2048 \
    -device virtio-scsi-pci,id=scsi0 \
    -device isa-fdc,id=floppy-bus \
    -drive file=/var/tmp/rhbz-2074805/disks-pc-sda,format=raw,if=none,id=drive-vblk-0,media=disk \
    -device virtio-blk-pci,drive=drive-vblk-0 \
    -drive file=/var/tmp/rhbz-2074805/disks-pc-sdb,format=raw,if=none,id=drive-vblk-1,media=disk \
    -device virtio-blk-pci,drive=drive-vblk-1 \
    -drive file=/var/tmp/rhbz-2074805/disks-pc-sdc,format=raw,if=none,id=drive-vblk-2,media=disk \
    -device virtio-blk-pci,drive=drive-vblk-2 \
    -drive file=/var/tmp/rhbz-2074805/disks-pc-sdd,format=raw,if=none,id=drive-vblk-3,media=disk \
    -device virtio-blk-pci,drive=drive-vblk-3 \
    -drive file=/var/tmp/rhbz-2074805/disks-pc-sde,format=raw,if=none,id=drive-vblk-4,media=disk \
    -device virtio-blk-pci,drive=drive-vblk-4 \
    -drive file=/var/tmp/rhbz-2074805/disks-pc-sdf,format=raw,if=none,id=drive-vblk-5,media=disk \
    -device virtio-blk-pci,drive=drive-vblk-5 \
    -drive if=none,id=drive-ide-0,media=cdrom \
    -device ide-cd,bus=ide.0,unit=0,drive=drive-ide-0 \
    -drive if=none,id=drive-ide-1,media=cdrom \
    -device ide-cd,bus=ide.1,unit=0,drive=drive-ide-1 \
    -drive if=none,id=drive-scsi-2,media=cdrom \
    -device scsi-cd,lun=2,drive=drive-scsi-2 \
    -drive if=none,id=drive-scsi-3,media=cdrom \
    -device scsi-cd,lun=3,drive=drive-scsi-3 \
    -drive if=none,id=drive-floppy-0,media=disk \
    -device floppy,bus=floppy-bus.0,unit=0,drive=drive-floppy-0 \
    -drive if=none,id=drive-floppy-1,media=disk \
    -device floppy,bus=floppy-bus.0,unit=1,drive=drive-floppy-1 \
    -netdev user,id=net0 \
    -device virtio-net-pci,netdev=net0,mac=52:54:00:d2:4f:a0 \
    -spice port=5900,addr=127.0.0.1 \
    -vga std \
    -device intel-hda \
    -device hda-duplex \
    -object rng-random,filename=/dev/urandom,id=rng0 \
    -device virtio-rng-pci,rng=rng0 \
    -device virtio-balloon \
    -device pvpanic,ioport=0x505 \
    -device vhost-vsock-pci,guest-cid=220950 \
    -serial stdio

My problem with the patch is that it's very difficult to test it exhaustively. For example, testing the i440fx machine type *on output* is difficult, because almost all guest OSes we care about nowadays support q35, and so the destination machine type is almost invariably set to Q35. Furthermore, I have zero idea how to test the Virt machine type (aarch64) -- I started installing an aarch64 Fedora 35 guest, just for this, using multi-core TCG (8 cores), and it has not completed in 75 minutes.

So I think I'll post the patch as an RFC to the list, and if it looks sensible, I'll attempt to build a downstream (RHEL9) RPM with it, and ask Virt-Tools QE to test it as exhaustively as they can manage.

Interesting test cases are, describing the *destination* domain:

- i440fx machine with 2 IDE-CDs, 2 IDE-HDs, 2 floppies, 2 virtio-block devices, 2 SCSI-CDs, and 2 SCSI-HDs.

- q35 machine with the same disks / cd-roms / floppies as above (substitute "SATA" for "IDE", but that's really just naming) -- this is actually what I covered in comment 12, above.

- virt (aarch64) machine using 2 virtio-block devices, 2 SCSI-CDs, and 2 SCSI-HDs. (There is no floppy or IDE-anything or floppies on aarch64/virt.)

[virt-v2v RFC] output_qemu: rewrite output disk mapping
Message-Id: <20220414150729.7714-1-lersek>
https://listman.redhat.com/archives/libguestfs/2022-April/028668.html

Note that virt-v2v cannot process guest arch != host arch, so you'll have
to install an aarch64 guest and run virt-v2v (on another guest image) inside
that.  Which will be slow.  Very slow.  Nevertheless virt-builder has
images you can use for both:

$ virt-builder -l | grep fedora.*aarch64
fedora-35                aarch64    Fedora® 35 Server (aarch64)
fedora-21                aarch64    Fedora® 21 Server (aarch64)
fedora-22                aarch64    Fedora® 22 Server (aarch64)
fedora-23                aarch64    Fedora® 23 Server (aarch64)
fedora-24                aarch64    Fedora® 24 Server (aarch64)
fedora-25                aarch64    Fedora® 25 Server (aarch64)
fedora-26                aarch64    Fedora® 26 Server (aarch64)
fedora-27                aarch64    Fedora® 27 Server (aarch64)
fedora-29                aarch64    Fedora® 29 Server (aarch64)
fedora-30                aarch64    Fedora® 30 Server (aarch64)

I would recommend a Raspberry Pi 4 / 8GB if you can find one.

> My problem with the patch is that it's very difficult to test it exhaustively.
> For example, testing the i440fx machine type *on output* is difficult,

virt-builder has fedora-18 through fedora-22, and if my reading of the osinfo
database is correct those should all default to i440fx.

There is also an internal repo with RHEL releases back to 3.9.  Ping me
over mail if you don't have that.

The patch I posted can produce the following:
- virtio-scsi-pci
- isa-fdc
- virtio-blk-pci
- ide-hd
- ide-cd
- scsi-hd
- scsi-cd
- floppy

They can be exercised as follows (per
"convert/target_bus_assignment.ml"):
- virtio-scsi-pci: produced if a scsi-hd or scsi-cd device will be
                   produced (see below)
- isa-fdc:         produced if a floppy will be produced (see below) but
                   only on Q35
- virtio-blk-pci:  produced for fixed disks if the guest has
                   virtio-block support
- ide-hd:          produced for fixed disks if the guest lacks
                   virtio-block support
- ide-cd:          produced for CD-ROMs if they are on IDE in the source
                   (note: not SATA, so the source must be i440fx)
- scsi-hd:         not possible to produce (hence, test), but this
                   branch is not difficult to review anyway
- scsi-cd:         produced for CD-ROMs if they are on SATA (q35) in the
                   source, or virtio-scsi (regardless of machine type)
- floppy:          produced for floppies (regardless of machine type)

A complication is that ide-* has different bus/unit assignments on
i440fx vs. q35 due to their different IDE / SATA (AHCI) controllers.
ide-hd is not possible to test on q35 (output), because that would
require a guest supporting q35 but *not* supporting virtio-blk -- and
virtio-blk far predates q35.

I've created the following script for outputting a very manageable set
of test scenarios:

> #!/bin/bash
> {
>   echo machine virtio_scsi_pci isa_fdc virtio_blk_pci scsi_cd floppy ide
>   for virtio_scsi_pci in 0 1; do
>     for isa_fdc in 0 1; do
>       for virtio_blk_pci in 0 2; do
>         # scsi_hds are not possible to test, see above
>         for scsi_cd in 0 2; do
>           for floppy in 0 2; do
>             # hd4 is not more useful than hd2_cd2.
>             for ide in 0 cd4 hd2_cd2; do
>
>               # virtio_scsi_pci is needed IFF at least one scsi_cd is
>               # needed
>               if ([ $virtio_scsi_pci -eq 0 ] && [ $scsi_cd -ne 0 ]) ||
>                  ([ $virtio_scsi_pci -ne 0 ] && [ $scsi_cd -eq 0 ])
>               then
>                 continue
>               fi
>
>               # an isa-fdc is invalid in any case if there is no floppy
>               if [ $isa_fdc -ne 0 ] && [ $floppy -eq 0 ]; then
>                 continue
>               fi
>
>               # if we have a virtio-blk-pci device (that is, the guest
>               # supports virtio-blk-pci), then we won't map any fixed
>               # disks to IDE
>               if [ $virtio_blk_pci -ne 0 ] && [ $ide = hd2_cd2 ]; then
>                 continue
>               fi
>
>               # the ISA-FDC controller needs to be spelled out only on
>               # q35
>               if [ $isa_fdc -ne 0 ]; then
>                 machine=q35
>               else
>                 machine=pc
>               fi
>
>               # on a guest OS that supports a q35 target machine type,
>               # we'll definitely have virtio-blk-pci support too (see
>               # above), hence we will map no fixed disks to IDE
>               if [ $machine = q35 ] && [ $ide = hd2_cd2 ]; then
>                 continue
>               fi
>
>               # if the target machine is pc, then covering the 4 IDE
>               # drives exclusively with CD-ROMs is not necessary:
>               # namely, if the target machine is pc, then it may lack
>               # virtio-blk-pci support, and therefore ide-hd's may
>               # survive as such. Therefore, the hd2_cd2 config suffices,
>               # and we need not care about cd4.
>               if [ $machine = pc ] && [ $ide = cd4 ]; then
>                 continue
>               fi
>
>               # The guest needs *some* fixed disks.
>               if [ $virtio_blk_pci -eq 0 ] && [ $ide != hd2_cd2 ]; then
>                 continue
>               fi
>
>               echo $machine $virtio_scsi_pci $isa_fdc $virtio_blk_pci \
>                    $scsi_cd  $floppy $ide
>             done
>           done
>         done
>       done
>     done
>   done
> } | column -t | sort

Note that the goal here is *not* to cross-test every branch
independently (that is, to test every possible *path*); instead, the
goal is to cover each branch in isolation -- to check whether the
created QEMU options are valid.

This script produces (machine means "target machine"):

> machine  virtio_scsi_pci  isa_fdc  virtio_blk_pci  scsi_cd  floppy  ide
> pc       0                0        0               0        0       hd2_cd2
> pc       0                0        0               0        2       hd2_cd2
> pc       0                0        2               0        0       0
> pc       0                0        2               0        2       0
> pc       1                0        0               2        0       hd2_cd2
> pc       1                0        0               2        2       hd2_cd2
> pc       1                0        2               2        0       0
> pc       1                0        2               2        2       0
> q35      0                1        2               0        2       0
> q35      0                1        2               0        2       cd4
> q35      1                1        2               2        2       0
> q35      1                1        2               2        2       cd4

This can be further squashed down as follows:

- The very last line determines our test case (1). It involves a
  *source* i440fx machine that is flipped to q35 on the destination
  (hence, a modern guest OS), and has 2 virtio-blk disks, 2 scsi-cds, 2
  floppies, and 4 ide cds. With this we can actually remove all the
  other q35 lines.

- From the pc lines, we can eliminate all lines that have either 2
  virtio-blk disks (4 lines removed), or 2 scsi-cds (2 more lines
  removed), or 2 floppies (1 more line removed) -- just one line
  remains:

> machine  virtio_scsi_pci  isa_fdc  virtio_blk_pci  scsi_cd  floppy  ide
> pc       0                0        0               0        0       hd2_cd2

  So this is our test case (2): i440fx source machine that remains
  i440fx after conversion, has no virtio-blk driver (so very old guest
  OS), and has 2 ide HDs, and 2 ide CDs.

I've eyeballed each test case through the code, and together they
provide complete branch coverage, as far as QEMU option production is
concerned (except for scsi-hd, which is impossible to cover, see above).

For test case 1, I'll use a Fedora 35 guest OS. For test case 2, I'll use RHEL-3.9.

Created attachment 1872706 [details]
test 1 source domain XML

Created attachment 1872707 [details]
test 1 destination QEMU script

Created attachment 1872708 [details]
test 2 source domain XML

Created attachment 1872709 [details]
test 2 destination QEMU script

I've also successfully booted the converted guests (comment 20, comment 22).

[v2v PATCH] output_qemu: rewrite output disk mapping
Message-Id: <20220415084728.14366-1-lersek>
https://listman.redhat.com/archives/libguestfs/2022-April/028678.html

(In reply to Laszlo Ersek from comment #24)
> [v2v PATCH] output_qemu: rewrite output disk mapping
> Message-Id: <20220415084728.14366-1-lersek>
> https://listman.redhat.com/archives/libguestfs/2022-April/028678.html

Merged upstream as commit 8643970f9791.

Let's pick this up in the next rebase.

Verify the bug with below builds:
virt-v2v-2.0.4-1.el9.x86_64
libguestfs-1.48.1-1.el9.x86_64
guestfs-tools-1.48.0-1.el9.x86_64
libvirt-libs-8.2.0-1.el9.x86_64
qemu-img-7.0.0-1.el9.x86_64
nbdkit-server-1.30.4-1.el9.x86_64
libnbd-1.12.2-1.el9.x86_64


Steps:
Scenario1:
1.1 Prepare a linux and windows guest which have attached a iso file to CD-ROM device on VMware env, then convert the guest from VMware to local qemu by v2v
#  virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0.3 -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-rhel9.1-x86_64 -ip /home/passwd  -o qemu -os /home

# virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0.3 -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA  esx6.7-win11-vmware-tools-enable-vapp-option  -ip /home/passwd -o qemu -os /home

1.2 Check files which is created by v2v
# ls /home/esx7.0-rhel9.1-x86_64
esx7.0-rhel9.1-x86_64-sda  esx7.0-rhel9.1-x86_64.sh   

# ls /home/esx6.7-win11-vmware-tools-enable-vapp-option
esx6.7-win11-vmware-tools-enable-vapp-option-sda  esx6.7-win11-vmware-tools-enable-vapp-option.sh

1.3 Check the shell file of guest
# cat esx7.0-rhel9.1-x86_64.sh
#!/bin/sh -

/usr/libexec/qemu-kvm \
    -no-user-config \
    -nodefaults \
    -name esx7.0-rhel9.1-x86_64 \
    -machine q35,accel=kvm:tcg \
    -m 2048 \
    -cpu host \
    -device virtio-scsi-pci,id=scsi0 \
    -drive file=/home/esx7.0-rhel9.1-x86_64-sda,format=raw,if=none,id=drive-vblk-0,media=disk \
    -device virtio-blk-pci,drive=drive-vblk-0 \
    -drive if=none,id=drive-scsi-0,media=cdrom \
    -device scsi-cd,bus=scsi0.0,lun=0,drive=drive-scsi-0 \
    -netdev user,id=net0 \
    -device virtio-net-pci,netdev=net0,mac=00:50:56:83:8e:f6 \
    -object rng-random,filename=/dev/urandom,id=rng0 \
    -device virtio-rng-pci,rng=rng0 \
    -device virtio-balloon \
    -device pvpanic,ioport=0x505 \
    -device vhost-vsock-pci,guest-cid=8987 \
    -serial stdio

# cat /home/esx6.7-win11-vmware-tools-enable-vapp-option.sh 
#!/bin/sh -

/usr/libexec/qemu-kvm \
    -no-user-config \
    -nodefaults \
    -name esx6.7-win11-vmware-tools-enable-vapp-option \
    -device vmgenid,guid=1568f131-26c7-3014-09e3-e6d02f2108a1,id=vmgenid0 \
    -machine q35,accel=kvm:tcg \
    -m 2048 \
    -device virtio-scsi-pci,id=scsi0 \
    -drive file=/home/esx6.7-win11-vmware-tools-enable-vapp-option-sda,format=raw,if=none,id=drive-vblk-0,media=disk \
    -device virtio-blk-pci,drive=drive-vblk-0 \
    -drive if=none,id=drive-scsi-0,media=cdrom \
    -device scsi-cd,bus=scsi0.0,lun=0,drive=drive-scsi-0 \
    -netdev user,id=net0 \
    -device virtio-net-pci,netdev=net0,mac=00:50:56:ac:e3:7b \
    -object rng-random,filename=/dev/urandom,id=rng0 \
    -device virtio-rng-pci,rng=rng0 \
    -device virtio-balloon \
    -device pvpanic,ioport=0x505

1.4 Try to create guest from qemu shell file
# ./esx7.0-rhel9.1-x86_64.sh
VNC server running on ::1:5900

# ./esx6.7-win11-vmware-tools-enable-vapp-option.sh
VNC server running on ::1:5900


Scenario2:
2.1 Prepare a windows uefi guest on VMware env, then convert the guest from VMware to local qemu 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.3 -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA  esx6.7-win10-x86_64-efi -ip /home/passwd -o qemu -os /home

2.2 Check files which is created by v2v
# ls /home/esx6.7-win10-x86_64-efi
esx6.7-win10-x86_64-efi-sda  esx6.7-win10-x86_64-efi.sh  

2.3 Check the shell file of guest
# cat /home/esx6.7-win10-x86_64-efi.sh 
#!/bin/sh -

# Make a copy of the UEFI variables template
uefi_vars="$(mktemp)"
cp '/usr/share/OVMF/OVMF_VARS.fd' "$uefi_vars"

/usr/libexec/qemu-kvm \
    -no-user-config \
    -nodefaults \
    -name esx6.7-win10-x86_64-efi \
    -device vmgenid,guid=afcb8d61-c6e0-f21f-c735-a9d307a48270,id=vmgenid0 \
    -machine q35,smm=on,accel=kvm:tcg \
    -global driver=cfi.pflash01,property=secure,value=on \
    -drive if=pflash,format=raw,file=/usr/share/OVMF/OVMF_CODE.secboot.fd,readonly \
    -drive if=pflash,format=raw,file="$uefi_vars" \
    -m 2048 \
    -smp cpus=2,sockets=1,cores=2,threads=1 \
    -drive file=/home/esx6.7-win10-x86_64-efi-sda,format=raw,if=none,id=drive-vblk-0,media=disk \
    -device virtio-blk-pci,drive=drive-vblk-0 \
    -netdev user,id=net0 \
    -device virtio-net-pci,netdev=net0,mac=00:50:56:ac:a0:b9 \
    -object rng-random,filename=/dev/urandom,id=rng0 \
    -device virtio-rng-pci,rng=rng0 \
    -device virtio-balloon \
    -device pvpanic,ioport=0x505

2.4 Try to create guest from qemu shell file
# ./esx6.7-win10-x86_64-efi.sh
qemu-kvm: -drive if=pflash,format=raw,file=/usr/share/OVMF/OVMF_CODE.secboot.fd,readonly: warning: short-form boolean option 'readonly' deprecated
Please use readonly=on instead
VNC server running on ::1:5900


Hi Laszlo,
    Please help to check step2.4, there is qemu-kvm warning after converting uefi guest to qemu, is it expected? Thanks!

I guess qemu wants 'readonly=on' there.  I don't think that affects verification
of this bug, but it would be nice to fix it since qemu has a habit of removing
deprecated features.

I too think that it's harmless for now, and that it should not block the verification of this bug. I'll send an independent patch later.

Thanks Richard and Laszlo, use bug2082603 to track the problem of step2.4, 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 (Low: virt-v2v security, 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/RHSA-2022:7968