RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2074805 - -o qemu mode fails with: qemu-system-x86_64: -balloon: invalid option and other problems
Summary: -o qemu mode fails with: qemu-system-x86_64: -balloon: invalid option and oth...
Keywords:
Status: CLOSED ERRATA
Alias: None
Deadline: 2022-08-29
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: virt-v2v
Version: 9.1
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Laszlo Ersek
QA Contact: mxie@redhat.com
URL:
Whiteboard:
Depends On: 2059287
Blocks: 2074818
TreeView+ depends on / blocked
 
Reported: 2022-04-13 06:45 UTC by mxie@redhat.com
Modified: 2022-11-15 10:24 UTC (History)
10 users (show)

Fixed In Version: virt-v2v-2.0.7-1.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-15 09:56:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
test 1 source domain XML (6.19 KB, text/plain)
2022-04-15 08:35 UTC, Laszlo Ersek
no flags Details
test 1 destination QEMU script (1.82 KB, text/plain)
2022-04-15 08:35 UTC, Laszlo Ersek
no flags Details
test 2 source domain XML (3.66 KB, text/plain)
2022-04-15 08:36 UTC, Laszlo Ersek
no flags Details
test 2 destination QEMU script (870 bytes, text/plain)
2022-04-15 08:36 UTC, Laszlo Ersek
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-118766 0 None None None 2022-04-13 06:56:17 UTC
Red Hat Product Errata RHSA-2022:7968 0 None None None 2022-11-15 09:56:20 UTC

Description mxie@redhat.com 2022-04-13 06:45:28 UTC
Description of problem:
Failed to create guest from qemu shell file after v2v converting to qemu

Version-Release number of selected component (if applicable):
virt-v2v-2.0.3-1.el9.x86_64
libguestfs-1.48.0-2.el9.x86_64
guestfs-tools-1.48.0-1.el9.x86_64
libvirt-libs-8.2.0-1.el9.x86_64
qemu-kvm-6.2.0-12.el9.x86_64
nbdkit-server-1.30.2-1.el9.x86_64
libnbd-1.12.2-1.el9.x86_64


How reproducible:
100%

Steps to Reproduce:
1. Convert a 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-rhel8.5-x86_64 -ip /home/passwd   -o qemu -os /home

2.# ls /home/esx7.0-rhel8.5-x86_64
esx7.0-rhel8.5-x86_64-sda  esx7.0-rhel8.5-x86_64.sh 

3. Try to create guest from qemu shell file
# ./esx7.0-rhel8.5-x86_64.sh
qemu-kvm: -balloon: invalid option

4. Comment balloon device in shell script# 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 \
#   -balloon virtio \
    -device pvpanic,ioport=0x505 \
    -device vhost-vsock-pci \
    -serial stdio
5. Try to create guest from qemu shell file again
# ./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"
./esx7.0-rhel8.5-x86_64.sh: line 16: -device: command not found

6. Comment cdrom device in shell file# 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 \
#   -balloon virtio \
    -device pvpanic,ioport=0x505 \
    -device vhost-vsock-pci \
    -serial stdio
7. Try to create guest from qemu shell file again
# ./esx7.0-rhel8.5-x86_64.sh
VNC server running on ::1:5900

Expected results:
As above description

Additional info:

Comment 2 Richard W.M. Jones 2022-04-13 08:42:53 UTC
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.

Comment 3 mxie@redhat.com 2022-04-13 09:19:33 UTC
(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"

Comment 4 Richard W.M. Jones 2022-04-13 09:25:30 UTC
Partial patch posted (not including the CD-ROM fix):
https://listman.redhat.com/archives/libguestfs/2022-April/028656.html

Comment 5 Richard W.M. Jones 2022-04-13 11:53:22 UTC
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.

Comment 6 Richard W.M. Jones 2022-04-13 12:22:06 UTC
(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.

Comment 7 Laszlo Ersek 2022-04-13 12:47:35 UTC
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

Comment 8 Laszlo Ersek 2022-04-13 13:04:55 UTC
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"...

Comment 9 Laszlo Ersek 2022-04-13 13:07:01 UTC
Let me look into this later.

Comment 10 mxie@redhat.com 2022-04-14 07:06:31 UTC
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>

Comment 11 Richard W.M. Jones 2022-04-14 07:45:44 UTC
(We don't try to copy over ISOs attached to guests.)

Comment 12 Laszlo Ersek 2022-04-14 15:01:30 UTC
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.

Comment 13 Laszlo Ersek 2022-04-14 15:04:34 UTC
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.)

Comment 14 Laszlo Ersek 2022-04-14 15:07:56 UTC
[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

Comment 15 Richard W.M. Jones 2022-04-14 15:12:24 UTC
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.

Comment 16 Richard W.M. Jones 2022-04-14 15:35:11 UTC
> 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.

Comment 17 Laszlo Ersek 2022-04-15 05:33:54 UTC
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).

Comment 18 Laszlo Ersek 2022-04-15 05:51:32 UTC
For test case 1, I'll use a Fedora 35 guest OS. For test case 2, I'll use RHEL-3.9.

Comment 19 Laszlo Ersek 2022-04-15 08:35:24 UTC
Created attachment 1872706 [details]
test 1 source domain XML

Comment 20 Laszlo Ersek 2022-04-15 08:35:38 UTC
Created attachment 1872707 [details]
test 1 destination QEMU script

Comment 21 Laszlo Ersek 2022-04-15 08:36:07 UTC
Created attachment 1872708 [details]
test 2 source domain XML

Comment 22 Laszlo Ersek 2022-04-15 08:36:15 UTC
Created attachment 1872709 [details]
test 2 destination QEMU script

Comment 23 Laszlo Ersek 2022-04-15 08:47:10 UTC
I've also successfully booted the converted guests (comment 20, comment 22).

Comment 24 Laszlo Ersek 2022-04-15 08:48:02 UTC
[v2v PATCH] output_qemu: rewrite output disk mapping
Message-Id: <20220415084728.14366-1-lersek>
https://listman.redhat.com/archives/libguestfs/2022-April/028678.html

Comment 25 Laszlo Ersek 2022-04-18 12:09:21 UTC
(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.

Comment 26 Richard W.M. Jones 2022-04-20 12:20:15 UTC
Let's pick this up in the next rebase.

Comment 30 mxie@redhat.com 2022-05-05 14:41:17 UTC
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!

Comment 31 Richard W.M. Jones 2022-05-05 14:50:54 UTC
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.

Comment 32 Laszlo Ersek 2022-05-06 12:23:33 UTC
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.

Comment 33 mxie@redhat.com 2022-05-06 14:20:12 UTC
Thanks Richard and Laszlo, use bug2082603 to track the problem of step2.4, move the bug from ON_QA to VERIFIED

Comment 35 errata-xmlrpc 2022-11-15 09:56:05 UTC
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


Note You need to log in before you can comment on or make changes to this bug.