Description of problem: [RFE]virt-v2v new feature "--vdsm-compat" should be implemented in VDSM . Version-Release number of selected component (if applicable): virt-v2v-1.32.7-3.el7_3.2.x86_64 libguestfs-1.32.7-3.el7_3.2.x86_64 RHV4.0: 4.0.6.3-0.1.el7ev How reproducible: 100% Steps to Reproduce: Scenario 1: 1.Prepare a guest with qcow2 format which compat=1.1 in kvm server. 2.Copy the guest to the host which register in rhv4.0 3.Import it from RHV4.0 GUI --> virtual machines tab --> import --> select KVM (via libvirt). 4.After convention successfully,check the guest format : #qemu-img info 30c49bce-221c-4c2b-8aac-2711e691d93e image: 30c49bce-221c-4c2b-8aac-2711e691d93e file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 5.6G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false Result: Guest disk will keep qcow2 with flag compat=1.1 when import from GUI. Scenario 2: 1.Prepare a guest with qcow2 format which compat=0.10 in kvm server 2.Copy the guest to the host which register in rhv4.0 3.Import it from GUI --> virtual machines tab --> import --> select KVM (via libvirt). After convention successfully,check the format : #qemu-img info 64cde4d0-cc80-477d-9d14-d5a6164fafa3 image: 64cde4d0-cc80-477d-9d14-d5a6164fafa3 file format: qcow2 virtual size: 7.0G (7516192768 bytes) disk size: 3.7G cluster_size: 65536 Format specific information: compat: 0.10 refcount bits: 16 Result: Guest disk will keep qcow2 with flag compat=0.10 when import from RHV4.0 GUI. Actual results: As above description Expected results: Import a guest from RHV GUI should be implemented virt-v2v new feature "--vdsm-compat". Because using virt-v2v to convert a guest to "-o vdsm" should has same behaviour with importing the guest in RHV (v2v integration with RHV). Addition info: 1.It is a new feature about virt-v2v, add a new option " --vdsm-compat=1.1 " flag with VDSM. As when run the command: #virt-v2v xen-pv-rhel6.7-x86_64 -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/c3fbdb8d-fe1b-4252-b2db-eb3edafc0c5e/master/vms/12345678-1234-1234-1234-123456789014 -os /mnt/c3fbdb8d-fe1b-4252-b2db-eb3edafc0c5e -of qcow2 --vdsm-compat=1.1 After conversion,the format of the guest will be qcow2 compat=1.1 2.If we don't add "--vdsm-compat=1.1",the format will be default qcow2 compat=0.10 ((for more message about the new feature https://bugzilla.redhat.com/show_bug.cgi?id=1400205))
It's important to say first that VDSM's behaviour doesn't need to be changed right now. Without using the --vdsm-compat flag at all, virt-v2v will continue to create compat=0.10 images which are compatible with RHEL 6 and RHEL 7 (albeit suboptimal). However once RHV drops support for RHEL 6, it may wish to use the --vdsm-compat=1.1 flag (this is assuming that the images will never need to be opened on RHEL 6 machines for any reason). What VDSM specifically needs to do is: (1) Check that the virt-v2v --machine-readable flag outputs: $ virt-v2v --machine-readable virt-v2v ... vdsm-compat-option <-- this indicates the flag is supported (2) Add the option to the command line: virt-v2v -o vdsm --vdsm-compat=1.1 [...]
Verification build: ovirt-engine-4.2.0-0.0.master.20170811144920.gita423008.el7.centos vdsm-4.20.2-64.git072feb0.el7.centos.x86_64 libvirt-client-3.2.0-14.el7_4.2.x86_64 sanlock-3.5.0-1.el7.x86_64 qemu-kvm-rhev-2.9.0-14.el7.x86_64 virt-v2v-1.36.3-6.el7_4.2.x86_64
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.