Hide Forgot
Description of problem: Support for RHEV with RHEL 6 nodes required us to output the old style qcow2 compat=0.10 images. Since RHEV 3.6 GA, RHEL 6 has not been supported as a RHEV node type. There are significant downsides to using qcow2 compat=0.10 instead of the modern default (compat=1.1), so stop forcing compat=0.10 for these targets. Patch sent upstream: https://www.redhat.com/archives/libguestfs/2016-November/msg00130.html This bug is for tracking inclusion of this change in RHEL 7.4. Version-Release number of selected component (if applicable): 1.32
I modified the plan a little bit in the updated patch: https://www.redhat.com/archives/libguestfs/2016-December/msg00002.html There's now a new --vdsm-compat-11 flag which VDSM needs to pass if the node is using RHV >= 4.1 & RHEL >= 7. Eventually (not for this bug) the flag will become the default, when RHV 4.1 minimum is present everywhere.
New version of this patch: https://www.redhat.com/archives/libguestfs/2016-December/msg00032.html
Fixed with https://github.com/libguestfs/libguestfs/commit/bdaeeb4e606f3828887da87ad5acb4f7b49cfed5 which is in libguestfs >= 1.35.15.
Verify the bug with below builds: virt-v2v-1.36.2-1.el7.x86_64 libvirt-3.1.0-2.el7.x86_64 vdsm-4.19.4-1.el7ev.x86_64 Verify steps: Check the option "--vdsm-ovf-output" details on man page. #man virt-v2v ### --vdsm-compat=0.10 --vdsm-compat=1.1 If -o vdsm and the output format is qcow2, then we add the qcow2 compat=0.10 option to the output file for compatibility with RHEL 6 (see https://bugzilla.redhat.com/1145582). If --vdsm-compat=1.1 is used then modern qcow2 (compat=1.1) files are generated instead. Currently --vdsm-compat=0.10 is the default, but this will change to --vdsm-compat=1.1 in a future version of virt-v2v (when we can assume that everyone is using a modern version of qemu). Note this option only affects -o vdsm output. All other output modes (including -o rhev) generate modern qcow2 compat=1.1 files, always. ### Scenario 1: 1:Prepare a geust with format "qcow compat=0.10" ,then using virt-v2v convert guest to rhv4.1 with option "-of qcow2" # virt-v2v -i disk kvm-rhel7.1-x86_64-qcow2.img -o rhev -os 10.73.131.93:/home/nfs_export -of qcow2 2.After conversion successfully,check the format: #qemu-img info 61095968-bf03-4ad1-807b-eed855eb1737 image: 7a9cfb93-0397-40e7-87d0-89b9bb14f162 file format: qcow2 virtual size: 9.0G (9663676416 bytes) disk size: 4.4G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false Additions: 1:Convert a guest with format raw to rhv wiht option "-of qcow2",after conversion the format is qcow compat=1.1. 2:Convert a guest with format qcow compat=1.1 to rhv with option "-of qcow2",after conversion the format is qcow compat=1.1. Scenarion 2: 1:Prepare a guest with format "raw" , convert it to rhv4.1 using option "--vdsm-compat=0.10",after conversion the format is qcow compat=0.10. 2:Prepare a guest with format "raw" , convert it to rhv4.1 using option "--vdsm-compat=1.1" ,after conversion the format is qcow compat=1.1 Scenario 3: 1:Prepare a guest with format "raw",then convert it to rhv4.1 without option "--vdsm-compat" # virt-v2v win7-raw -o vdsm --vdsm-image-uuid 12345678-1234-1234-1234-123456789011 --vdsm-vol-uuid 12345678-1234-1234-1234-123456789012 --vdsm-vm-uuid 12345678-1234-1234-1234-123456789014 --vdsm-ovf-output /mnt/165c1942-70e7-4691-aa63-9184a0569bf2/master/vms/12345678-1234-1234-1234-123456789014 -os /mnt/165c1942-70e7-4691-aa63-9184a0569bf2 -of qcow2 2:After conversion successfully ,check the format: # qemu-img info 12345678-1234-1234-1234-123456789012 image: 12345678-1234-1234-1234-123456789012 file format: qcow2 virtual size: 12G (12884901888 bytes) disk size: 12G cluster_size: 65536 Format specific information: compat: 0.10 refcount bits: 16 Addition info: When using guest with fomat compat=0.10 and format compat=1.1 convert to rhv4.1 without option "--vdsm-compat" ,after conversion successfully,the format is qcow compat=0.10. So,all the Scenario results are expects, move the 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://access.redhat.com/errata/RHBA-2017:2023