Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Created attachment 1441758[details]
*.ovf file extracted from the ova with unknown VMware controller type (20)
Description of problem:
virt-v2v: warning: ova disk has an unknown VMware controller type (20),
please report this as a bug supplying the *.ovf file extracted from the ova
virt-v2v: warning: could not parse ovf:Name from OVF document
Version-Release number of selected component (if applicable):
$virt-v2v --version
virt-v2v 1.36.10rhel=7,release=6.el7_5.2,libvirt
How reproducible:
Totally
Steps to Reproduce:
Following https://access.redhat.com/articles/1351963
1. download ova from https://www.sagemath.org/download.html
Specifically used http://www.cecm.sfu.ca/sage/ova/sage-8.1.ova
2. unsure whether virt-v2v can handle .gz, so made sure .ova was simple tar.
Aside: .ova loads fine into Oracle VM VirtualBox 5.1 at this point.
3. sudo -v virt-v2v -i ova ~/Downloads/sage-8.1.ova -of qcow2 -os gnome-boxes
Actual results: conversion fails
The bug reported in problem desc is not the only issue, but is the only one being reported.
Expected results:
ova converted to qcow2, able to import into boxes.
Additional info:
virt-v2v also cannot find any space in gnome-boxes, although the verbose output indicates plenty. (This is a large VM.) I have not eliminated the possibility this is a permissioning or file location issue on my part, rather than a bug.
$sudo virsh list --all
also indicates gnome-boxes pool (and only gnome-boxes)
(In reply to Charles Evans from comment #0)
> Description of problem:
> virt-v2v: warning: ova disk has an unknown VMware controller type (20),
> please report this as a bug supplying the *.ovf file extracted from the ova
This is bug 1510801, so I'm marking this as duplicate of that one.
> virt-v2v: warning: could not parse ovf:Name from OVF document
This is because the VirtualBox OVa export (or something like that) does not produce fully compliant OVF files.
> Steps to Reproduce:
> Following https://access.redhat.com/articles/1351963
> 1. download ova from https://www.sagemath.org/download.html
> Specifically used http://www.cecm.sfu.ca/sage/ova/sage-8.1.ova
> 2. unsure whether virt-v2v can handle .gz, so made sure .ova was simple tar.
The OVAs found on the above locations are plain tar with no compression (as standard).
> 3. sudo -v virt-v2v -i ova ~/Downloads/sage-8.1.ova -of qcow2 -os gnome-boxes
Using sudo means the default libvirt connection used is qemu:///system (i.e. the system one), while I think gnome-boxes uses the user connection (qemu:///session) when running as user.
> Actual results: conversion fails
> The bug reported in problem desc is not the only issue, but is the only one
> being reported.
None of the two reported warnings of virt-v2v causes the failure of the conversion.
I don't see anything else that would indicate a conversion failure in virt-v2v itself. If so, please post a full log when running virt-v2v with -v -x (both).
*** This bug has been marked as a duplicate of bug 1510801 ***