Red Hat Bugzilla – Bug 1342398
Convert a guest from RHEL by virt-v2v but its origin info shows RHEV at rhevm
Last modified: 2016-11-03 14:00:58 EDT
Created attachment 1164366 [details] screenshot Description of problem: Convert a guest from RHEL by virt-v2v but its origin info shows RHEV at rhevm Version-Release number of selected component (if applicable): RHEVM:3.6.7.2-0.1.el6 Virt-v2v conversion server has below packages: qemu-kvm-1.5.3-113.el7.x86_64 kernel-3.10.0-418.el7.x86_64 libguestfs-1.32.4-3.el7.x86_64 virt-v2v-1.32.4-3.el7.x86_64 libvirt-1.3.4-1.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Convert a guest from vmware to rhevm by virt-v2v 2.Convert a guest from xen to rhevm by virt-v2v 3.Convert a guest from rhel to rhevm by virt-v2v 4.After conversion, check the guests' origin info at rhevm nfs_export domain, it shows as below 4.1 Guest which converted from vmware and its origin shows VMware 4.2 Guest which converted from XEN and its origin shows XEM 4.3 Guest which converted from RHEL but its origin shows RHEV, pls refer to screenshot Actual results: As above description Expected results: Convert a guest from RHEL by virt-v2v and its origin info should be RHEL at rhevm Additional info:
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