This issue was caused by the way libvirt uses apparmor.
The default behavior is to provide some protection for the host against the guest by restricting which files the virtualization process on the host is allowed to access. libvirt knows that the virtualization process (kvm in this case) needs the disk image in order to operate properly, so it creates an apparmor profile which allows access to windowsxp-1.qcow2. However, it doesn't know that windowsxp-1.qcow2 is backed by basewindowsxp.qcow2, so the apparmor profile doesn't allow access to that file.
It's unfortunate that the error reporting from kvm is so minimal. The underlying failure was almost certainly an EPERM when opening basewindowsxp.qcow, but apparently this error gets flattened out and the useful information lost.
However, reading the system logs will reveal that apparmor is doing something. For example,
May 28 13:12:28 hostname kernel: [ 5338.835932] type=1503 audit(1275066748.269:42): operation="open" pid=10601 parent=1 profile="libvirt-b1a29fd0-698c-11df-9c21-f78cb972735d" requested_mask="::w" denied_mask="::w" fsuid=0 ouid=1001 name="/var/lib/libvirt/images/basewindowsxp.img"
This shows what happens when an apparmor profile denies write access to a file for a process. Each time the vm startup failed because of this misconfiguration, this log message appeared in /var/log/messages.
There are several possible solutions to the problem.
1) Disable apparmor protection. This is controllable via the virt-manager GUI. In the overview section, security subsection, apparmor can be disabled.
2) Manually allow access to the extra file. This is controlled by modifying the apparmor files in /etc/apparmor.d/libvirt/ directory. Adding a line like:
"/var/lib/libvirt/images/basewindowsxp.img" r,
to the file matching the uuid of the vm in question will grant read access to the filename in quotes.
3) Upgrade to a newer version of apparmor/libvirt/the base platform and re-create the VMs. Apparently this misconfiguration has been noticed and is addressed automatically in new enough versions of the software in question.
Since you have the disk image from the export domain, why not simply create a new VM in virt-manager or virsh, with the same params the RHEV one had, and attach the disk image to it?
Best Answer
Another solution I found for the same conversion requirement is to install QEMU on Windows and use the same syntax as for regular qemu-img
Source for downloading the qemu binaries here or here