We don't really use that field for anything. I suppose it's a v2v bug?

Hi rjones,

Could you help to check whether this bug is related to v2v, attachment is virt-v2v log, thanks

Created attachment 1165886 [details]
virt-v2v.log

It seems to me, that virt-v2v can distinguish only between VMware, Xen and <something else> (which is Origin=0 as can be seen in the log). On the other hand, in oVirt Origin=0 is not something generic but means 'RHEV'.

Oh I'm sorry, we don't use virt-v2v for kvm conversion, so virt-v2v is irrelevant here. Shahar, add a new type in your script?

Fairly low prio unless you convince me otherwise

How did you import the VM?
@Michal I don't think he use VMs->Import Vm->KVM since it will be kvm as origin, what it looks like a usage of 'virt-v2v with -o rhev' option that copy the vm directory to export domain,
In this case the origin type should be generate via virt-v2v ovf file.

currently this is the options that we have:
--------------------------------
RHEV(0),
VMWARE(1),
XEN(2),
OVIRT(3),
// VMs that externally run on the host (not created by the engine)
EXTERNAL(4),
// VMs that were created by the hosted engine setup
HOSTED_ENGINE(5),
// managed means we allow limited provisioning on this VM by the engine
MANAGED_HOSTED_ENGINE(6),
KVM(7)
-------------------------------
if you don't set the origin type the default is 0 which is RHEV.
I do think it should be 4 ie external.

(In reply to Shahar Havivi from comment #6)
> currently this is the options that we have:
> --------------------------------
> RHEV(0),
> VMWARE(1),
> XEN(2),
> OVIRT(3),
> // VMs that externally run on the host (not created by the engine)
> EXTERNAL(4),
> // VMs that were created by the hosted engine setup
> HOSTED_ENGINE(5),
> // managed means we allow limited provisioning on this VM by the engine
> MANAGED_HOSTED_ENGINE(6),
> KVM(7)

Just from a virt-v2v point of view, this is interesting new information.
Currently virt-v2v only set the origin to VMware -> 1, Xen -> 2,
and anything else to 0 (which is wrong).

A posted a patch upstream which changes this:

https://www.redhat.com/archives/libguestfs/2016-June/msg00026.html

However that leaves some questions:

Is it OK to *omit* the Origin field -- will that break oVirt?  The proposed
patch will now omit the Origin field in cases where it does not know what to
set it to.

The other cases that I'm thinking about are:

 - Physical machines (ie. virt-p2v)

 - HyperV

I tried importing OVF without specified Origin. In the import dialog it says 'Origin: N/A' and after the import it says 'Origin: RHEV'.

(In reply to Richard W.M. Jones from comment #7)

> https://www.redhat.com/archives/libguestfs/2016-June/msg00026.html
I think 4 (external) is better then 7 (kvm) but its debatable...

> However that leaves some questions:
> 
> Is it OK to *omit* the Origin field -- will that break oVirt?  The proposed
> patch will now omit the Origin field in cases where it does not know what to
> set it to.
you can omit the Origin, it will not break since the default is RHEV but it will not be accurate....

> 
> The other cases that I'm thinking about are:
> 
>  - Physical machines (ie. virt-p2v)
> 
>  - HyperV
We need to add that fields in oVirt when relevant.

Thanks, this is what I pushed:
https://github.com/libguestfs/libguestfs/commit/9467777fdf08ef7158b63354b9b46b003845daee

Let me know when the other numbers are reserved.

I can reproduce this issue with build:
virt-v2v-1.32.4-3.el7.x86_64
libguestfs-1.32.4-3.el7.x86_64

Then try to verify this bug with new build:
libvirt-1.3.5-1.el7.x86_64
libguestfs-1.32.5-7.el7.x86_64
virt-v2v-1.32.5-7.el7.x86_64
qemu-kvm-1.5.3-116.el7.x86_64
kernel-3.10.0-453.el7.x86_64

1. Convert a rhel guest to rhevm server but failed.
# virt-v2v -o rhev -os 10.73.72.63:/home/nfs_export rhel6.8latest  -n ovirtmgmt -b ovirtmgmt -on juzhoutest3 -of raw
[   0.0] Opening the source -i libvirt rhel6.8latest
[   0.0] Creating an overlay to protect the source from being modified
[   0.1] Initializing the target -o rhev -os 10.73.72.63:/home/nfs_export
[   0.3] Opening the overlay
virt-v2v: error: libguestfs error: /usr/libexec/qemu-kvm exited with error 
status 127.
To see full error messages you may need to enable debugging.
Do:
  export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
and run the command again.  For further information, read:
  http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
You can also run 'libguestfs-test-tool' and post the *complete* output
into a bug report or message to the libguestfs mailing list.

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

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

Hi rjones, please help me check it, thanks.
I will attach virt-v2v debug log.

Created attachment 1173360 [details]
virt_v2v_debug_juzhoutest3.log

(In reply to zhoujunqin from comment #15)
> I can reproduce this issue with build:
> virt-v2v-1.32.4-3.el7.x86_64
> libguestfs-1.32.4-3.el7.x86_64
> 
> Then try to verify this bug with new build:
> libvirt-1.3.5-1.el7.x86_64
> libguestfs-1.32.5-7.el7.x86_64
> virt-v2v-1.32.5-7.el7.x86_64
> qemu-kvm-1.5.3-116.el7.x86_64
> kernel-3.10.0-453.el7.x86_64
> 
> 1. Convert a rhel guest to rhevm server but failed.
> # virt-v2v -o rhev -os 10.73.72.63:/home/nfs_export rhel6.8latest  -n
> ovirtmgmt -b ovirtmgmt -on juzhoutest3 -of raw
> [   0.0] Opening the source -i libvirt rhel6.8latest
> [   0.0] Creating an overlay to protect the source from being modified
> [   0.1] Initializing the target -o rhev -os 10.73.72.63:/home/nfs_export
> [   0.3] Opening the overlay
> virt-v2v: error: libguestfs error: /usr/libexec/qemu-kvm exited with error 
> status 127.
> To see full error messages you may need to enable debugging.
> Do:
>   export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
> and run the command again.  For further information, read:
>   http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
> You can also run 'libguestfs-test-tool' and post the *complete* output
> into a bug report or message to the libguestfs mailing list.
> 
> If reporting bugs, run virt-v2v with debugging enabled and include the 
> complete output:
> 
>   virt-v2v -v -x [...]
> 
> Hi rjones, please help me check it, thanks.
> I will attach virt-v2v debug log.

After debug this issue, file bug 1351106 against qemu-kvm component.
And thanks for rjones help, clear needinfo flag.

Try to verify with new build:
libguestfs-1.32.5-9.el7.x86_64
virt-v2v-1.32.5-9.el7.x86_64
qemu-kvm-1.5.3-116.el7.x86_64
libvirt-1.3.5-1.el7.x86_64

Steps:
1. Convert a guest from rhel7 to rhv.
# virt-v2v -o rhev -os 10.73.72.63:/home/nfs_export rhel7.2  -n ovirtmgmt -b ovirtmgmt -on juzhoutest-kvm -of qcow2

2. After conversion, login rhv and check its origin in nfs_export domain.

Result:
'juzhoutest-kvm 'origin shows 'N/A', after import to database, origin always keeps 'N/A'

So rjones from you patch, i think the right showing is 'QEmu | KVM'

+  | QEmu | KVM -> Some 7

Please help me check it, thanks.

Created attachment 1174324 [details]
virt_v2v_juzhoutest-kvm.log

Created attachment 1174325 [details]
juzhoutest-kvm.png

We're now setting the correct origin in the OVF, see comment 19:
    <Origin>7</Origin>
So it's up to RHEV to show the correct value instead of N/A.

I checked the oVirt Engine code and there is a missing property
which is probably why it's being displayed as N/A instead of "KVM".

I have filed bug 1351477.

(In reply to Richard W.M. Jones from comment #21)
> We're now setting the correct origin in the OVF, see comment 19:
>     <Origin>7</Origin>
> So it's up to RHEV to show the correct value instead of N/A.
> 
> I checked the oVirt Engine code and there is a missing property
> which is probably why it's being displayed as N/A instead of "KVM".
> 
> I have filed bug 1351477.

Thanks for your reply, i will verify this bug until bug 1351477 fixed.

Since bug 1351477 is ON_QA now, then update our rhevm4.0 to latest tree:
http://bob.eng.lab.tlv.redhat.com/builds/4.0/ovirt-4.0.2/el7/
Try to verify this bug again with package:

libguestfs-1.32.6-2.el7.x86_64
virt-v2v-1.32.6-2.el7.x86_64
libvirt-2.0.0-3.el7.x86_64

Steps:

1. Convert a guest from rhel7 to rhevm4.0
# virt-v2v -o rhev -os 10.66.4.143:/home/p2v_export juzhou-rhel6u8  -n ovirtmgmt -b ovirtmgmt -on juzhoutest3 -of raw
[   0.0] Opening the source -i libvirt juzhou-rhel6u8
[   0.0] Creating an overlay to protect the source from being modified
[   0.2] Initializing the target -o rhev -os 10.66.4.143:/home/p2v_export
[   0.4] Opening the overlay
[   4.2] Inspecting the overlay
[  14.6] Checking for sufficient free disk space in the guest
[  14.6] Estimating space required on target for each disk
[  14.6] Converting Red Hat Enterprise Linux Server release 6.8 (Santiago) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  49.4] Mapping filesystem data to avoid copying unused and blank areas
[  49.7] Closing the overlay
[  49.9] Checking if the guest needs BIOS or UEFI to boot
[  49.9] Assigning disks to buses
[  49.9] Copying disk 1/1 to /tmp/v2v.uFeJ8k/1033c54b-dfde-4fbe-862d-6cfe26214efb/images/2e26ae9d-06f3-46b7-b87b-0c8a2e390c9c/b0605e59-264a-4bd7-b209-f6403f9abdb4 (raw)
    (100.00/100%)
[ 337.8] Creating output metadata
[ 337.9] Finishing off


2. After conversion, login rhevm and check its origin in p2v_export domain.

Result: 'juzhoutest3' origin shows 'KVM', after import to database, origin always keeps 'KVM'

Name         Template       Origin
juzhoutest3  Blank          KVM

3. Also checked with convert guest from xen/VMware to rhevm4.0, origin shows correctly.

Name           Template Origin
juzhoutestvpx  Blank	VMware

juzhoutestxen  Blank     Xen

Since origin shows correctly, move this 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, 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://rhn.redhat.com/errata/RHSA-2016-2576.html