Bug 1600547

I think this is a known bug.  You currently must use
‘-oa preallocated’.  Eventually we want to modify oVirt
so it does the right thing automatically.

See:
https://bugzilla.redhat.com/show_bug.cgi?id=1574734#c4

This bug is possibly a dupe of bug 1574734.

(In reply to Richard W.M. Jones from comment #2)
> I think this is a known bug.  You currently must use
> ‘-oa preallocated’.  Eventually we want to modify oVirt
> so it does the right thing automatically.
Hi rjones,

   Thanks reminding, convert guest to rhv4.2's iscsi data domain by virt-v2v (-1.38.2-7.el7.x86_64) with -oa preallocated, but conversion is still failed, pls refer to log "rhv-upload-iscsi_data-preallocated-7"

#virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1  esx6.7-win8.1-x86_64  -o rhv-upload -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -os iscsi_data -op /tmp/rhvpasswd -oo rhv-cafile=/root/ca.pem  -oo rhv-direct -of raw --password-file /tmp/passwd -b ovirtmgmt -oa preallocated
[   0.7] Opening the source -i libvirt -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win8.1-x86_64
[   3.3] Creating an overlay to protect the source from being modified
[   4.6] Initializing the target -o rhv-upload -oa preallocated -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os iscsi_data
[   6.5] Opening the overlay
[  26.6] Inspecting the overlay
[ 157.2] Checking for sufficient free disk space in the guest
[ 157.2] Estimating space required on target for each disk
[ 157.2] Converting Windows 8.1 Enterprise to run on KVM
virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing.  
Firstboot scripts may conflict with PnP.
virt-v2v: warning: there is no QXL driver for this version of Windows (6.3 
x86_64).  virt-v2v looks for this driver in 
/usr/share/virtio-win/virtio-win.iso

The guest will be configured to use a basic VGA display driver.
virt-v2v: This guest has virtio drivers installed.
[ 192.4] Mapping filesystem data to avoid copying unused and blank areas
[ 195.0] Closing the overlay
[ 195.8] Checking if the guest needs BIOS or UEFI to boot
[ 195.8] Assigning disks to buses
[ 195.8] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.zv6QI4/nbdkit1.sock", "file.export": "/" } (raw)
    (100.00/100%)
[1767.2] Creating output metadata
Traceback (most recent call last):
  File "/var/tmp/rhvupload.zv6QI4/rhv-upload-createvm.py", line 95, in <module>
    data = ovf,
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 33829, in add
    return self._internal_add(vm, headers, query, wait)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 232, in _internal_add
    return future.wait() if wait else future
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 55, in wait
    return self._code(response)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 229, in callback
    self._check_fault(response)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 132, in _check_fault
    self._raise_error(response, body)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 118, in _raise_error
    raise error
ovirtsdk4.NotFoundError: Fault reason is "Operation Failed". Fault detail is "Entity not found: Cluster: name=Default". HTTP response code is 404.
virt-v2v: error: failed to create virtual machine, see earlier errors

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]

Created attachment 1458846 [details]
rhv-upload-iscsi_data-preallocated-7.log

I guess we should try to either catch these errors or at
least make the error message clearer.  In any case:

> Fault detail is "Entity not found: Cluster: name=Default".

This mean that you used the wrong cluster name.  You have to
select the right cluster using

  virt-v2v .. -oo rhv-cluster=CLUSTER

(the default for CLUSTER if omitted is "Default").

Sorry, I didn't check the error carefully, the conversion could be finished without error after setting correct cluster,  I think it would be better if the error is reported before copying like MAC problem which is discussing in bug1557273, Thanks


#  virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1  esx6.7-win8.1-x86_64  -o rhv-upload -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -os iscsi_data -op /tmp/rhvpasswd -oo rhv-cafile=/root/ca.pem  -oo rhv-direct -of raw --password-file /tmp/passwd -b ovirtmgmt -oa preallocated -oo rhv-cluster=ISCSI
[   0.4] Opening the source -i libvirt -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win8.1-x86_64
[   2.8] Creating an overlay to protect the source from being modified
[   3.9] Initializing the target -o rhv-upload -oa preallocated -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os iscsi_data
[   5.6] Opening the overlay
[  19.7] Inspecting the overlay
[ 148.6] Checking for sufficient free disk space in the guest
[ 148.6] Estimating space required on target for each disk
[ 148.6] Converting Windows 8.1 Enterprise to run on KVM
virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing.  
Firstboot scripts may conflict with PnP.
virt-v2v: warning: there is no QXL driver for this version of Windows (6.3 
x86_64).  virt-v2v looks for this driver in 
/usr/share/virtio-win/virtio-win.iso

The guest will be configured to use a basic VGA display driver.
virt-v2v: This guest has virtio drivers installed.
[ 181.0] Mapping filesystem data to avoid copying unused and blank areas
[ 182.4] Closing the overlay
[ 183.0] Checking if the guest needs BIOS or UEFI to boot
[ 183.0] Assigning disks to buses
[ 183.0] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.CerJn2/nbdkit1.sock", "file.export": "/" } (raw)
    (100.00/100%)
[1744.2] Creating output metadata
[1761.9] Finishing off

raw sparse image will never be supported for block storage, so this bug can be 
closed.

I think the real issue is failing too late - only after preparing the image which
takes about 3 minutes. If we separate disk creation from conversion, we can fail
very quickly (in few seconds) when creating a disk with invalid onfiguration.
But this should probably be handled in a new RFE.

I'm closing this because we're not planning any more work beyond RHEL 7.7.
In any case this bug seems like it's not a bug in virt-v2v, or if it is then
it's best handled as an RFE against upstream or RHEL 8.